ASE : récupération d'une table dont le chaînage est corrompu || Cours gratuit au format pdf

» Mot de passe oubli�

» Inscription

Accueil

Contact

Info

Catégories

Télécharger

Menu Principal / Informatiques / Bases de données / SQL server / ASE : récupération d'une table dont le chaînage est corrompu

ASE : récupération d'une table dont le chaînage est corrompu

Il peut arriver qu'un fichier de base de données ait été corrompu par un problème matériel (fichier corrompu, disque abîmé, bug d'un contrôleur disque, etc.).
Soulignons le fait que certaines des commandes qui vont suivre sont extrêmement intrusives. Il convient donc d'avoir une bonne connaissance du moteur de la base avant de se lancer dans une telle démarche.
La procédure officielle de récupération de données après un crash est de remonter une sauvegarde effectuée précédemment. Il se peut malheureusement que les sauvegardes précédentes aient déjà été corrompues. D'expérience, il apparaît que peu de DBA exécutent les commandes de vérification de validité (dbcc checkdb, dbcc checkalloc, dbcc checkcatalog) de la base avant d'exécuter les sauvegarde. La mise en place d'une stratégie permettant de minimiser les temps morts d'un moteur (sauvegardes, réplications, haute disponibilité, etc) est la pierre angulaire d'une environnement stable, mais cette partie ne sera pas couverte ici.
Une autre source importante permettant de résoudre un certain nombre d'erreurs et le Troubleshooting and Error Messages Guide.
Cette procédure a été validée sur un serveur Sybase ASE version 12.x.
La plupart des tables de Sybase ASE sont, de manière interne, stockées sur des pages de données liées entre elles par des pointeurs.

Commentaires:

Namari
Invité

The paagorn of understanding these issues is right here!

The paagorn of understanding these issues is right here!

22.03.2013 03:18

Muna
Invité

Hi PeterAt the risk of sounding like I'm in sales, I like to point out that Sybase was the first cmopany to release a commercial grade RDBMS product on the Linux platform. We released the Sybase SQL Server 11.0.3.3 ESD#2 (our original name before MS somehow ended up with it) on September 23, 1998. This was the year before both Oracle and IBM released their versions I guess one of Oracle's self-proclaimed first's is not quite accurate!In any event, Linux is clearly a great platform for Sybase and ASE as we share many of the same design principles around resource efficiency. It is one of our primary development platforms for us meaning that engineers are required to check-in features to this platform concurrently with Windows and one of the major Unix's (Solaris/SPARC, HP-UX, and AIX). So, users can be guaranteed that Linux will benefit from new and useful capabilities that we are developing for people looking for highly performant and scalable RDBMS which places a premium on using HW/OS resources as efficiently as possible to get the most out of the box.Thanks again for the plug Peter ThawleySenior Director/Architect, CTO GroupSybase, Inc.

03.02.2015 00:25

Amanda
Invité

Hi Peter,Thanks a lot for all those updates. It is very exniticg to know about future database features. I worked long time as Sybase DBA and also in Oracle. As per you have mentioned in your write-up, I am suggesting Sybase for long time to implement Dynamic RDBMS. This RDBMS will adjust it's all configurations for the best performance to adjust to the Peak Load on the Database, OLTP, DSS, Response time, throughput Dynamically (on it's own). There is no need of baby sitting of Database and endless tuning required. I am sure if this is implemented in any RDBMS that product will have maximum Database market share in the world. We need this kind of database technology in the near market to compete with data growth, application response time, throughput etc. and compete with other database vendors. So if this is coming with SQL Server 2010 they have very bright future !!

03.02.2015 04:31